NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part1/5606

Text File | 1996-08-05 | 6.1 KB | 137 lines

Newsgroups: comp.lang.c
Path: uu4news.netcom.com!zodiac!szh
From: [e-mail] (Syed Zaeem Hosain)
Subject: Re: What to do when feof() is NOT feof()
Message-ID: <[e-mail]>
Sender: [e-mail] (Syed Zaeem Hosain)
Nntp-Posting-Host: zodiac
Reply-To: [e-mail]
Organization: Z Consulting Group
References: <4g9tph$[e-mail]>
Date: Mon, 19 Feb 1996 22:56:04 GMT

In article <4g9tph$[e-mail]>, [e-mail] (Aubrey Harrison) writes:
>In article <[e-mail]>, [e-mail]∞ says...
>[snip]
>>On my SunOS system, there is no such ascii 26 byte denoting end of file
>>and fgets will *not* terminate in this manner. The point is that by
>>making such incorrect responses (like you did by insisting on this
>>point) is just plain wrong. It has nothing to do with the language or
>>how the end of files are denoted in most operating systems. Even in
>>PC's running MSDOS, there is no such requirement that there *must* be
>>an ascii 26 at the end of text files. Certain editors (Brief is an
>>example. microEMacs is another) can easily be configured to create such
>>ascii files without this byte.
>>
>>Note that even the EOF result returned (look in stdio.h) has nothing to
>>do with the actual byte at the end of the file.
>>
>>The bottom line still is: please do not offer answers if you do not
>>know the correct answer.
>
>Nowhere did I say a file had to end with an ascii 26.

Agreed, you did not say that exactly. But let's look at your *exact*
words, shall we? In <4g4vpp$[e-mail]> you wrote:

    I think if you open the file in "text" mode the end of the file
    is indicated by the EOF marker (ASCII 26 I believe).

Would you not agree that my interpretation and response in my post is a
reasonable way to deal with what you actually said? I will clarify
further. When I spoke of my SunOS system, I was careful to say:

    no such ascii 26 byte denoting end of file

This is because in SunOS, a file is simply a file and no qualification
is needed. When I spoke of PC systems, I said:

    Even in PC's running MSDOS, there is no such requirement that
    there *must* be an ascii 26 at the end of text files.

The point is that I used the qualifier "text" when talking about PC
system files because of the specific response I was making to your
post. Again, this is because of the interpretation I made of your
words.

But if this was not a correct way of reading your words, my apologies!

>What I said (or I am
>trying to say), and this is true which is why I can't understand all this
>commotion... On an MS-DOS machine, using Microsoft C, if you do not tell fopen
>you are reading a binary file by using the "rb" parameter inputs such as fgets
>will stop reading and return end-of-file if it encounters an ascii 26 in the
>file. i.e. If the 654th byte of a 60,000 line file is an ascii 26, fgets will
>only read 654 bytes of the file.

The commotion is caused by the fact is that you did not limit your
original answer properly - your post effectively indicated that dealing
with byte value 26 was some general problem in C and fgets would fail.
This is a misleading and incorrect answer - just because the MSDOS
operating system OR Microsoft C do this behavior does not mean that the
C LANGUAGE is supposed to behave in this manner.

Yes, Dan was less than tactful in his response, but (and this is
important) he made a correct observation. In active newsgroups like
this, when we are all trying to learn from experts and be helpful to
others, posts that create further confusion only result in long-term
problems. There have been times when we all have been very frustrated
by people not following the simple rules that exist, and Dan merely has
less patience than others.

>Once again, the original message did not indicate what OS or compiler the
>person was using.

Exactly! Which is why your MS-DOS and Microsoft C specific response,
without qualification, could have sent that person barking up the wrong
tree.

>I should have been clearer in my response that I was
>referring to MS-DOS and Microsoft C.

Yes, absolutely! This is good form.

>I only responded because I have had the
>exact same problem and tracked it down to the fact that while the file I was
>reading was a "text" file there were a few bytes (including ascii 26) that were
>killing fgets and signalling end-of-file when it was not. Maybe he has some
>other problem, maybe he has the same problem. I don't know, and you don't know.
>I think the notion that the only help that could or should ever be given is an
>exact diagnoses and cure to a problem is a little ridiculous and unpractical.

Not really impractical at all. In many situations, exact answers on C
language issues can be (and often do get) provided by people who have
the expertise. Let them do so if you do not have the right answer.

The bottom line is:

1. If your answer is indeed restricted to a specific OS and/or compiler
and/or system implementation, then please do say so. This leads to less
confusion for the people asking questions.

2. We try very strongly to ask questions (and respond to them) in
non-system-specific ways because this is a newsgroup dedicated to
LANGUAGE discussions about C. When people need system-specific
information, there are plenty of other newsgroup dedicated to that
purpose (such as comp.os.msdos.programmer, comp.unix.programmer,
comp.os.ms-windows.programmer, etc.)

3. If you do not know the correct answer, please do not answer. There
are sufficient experts here who will post the correct answer (as and
when and if needed) in due time.

And to this, I would always add a general admonishment (which does not
apply to your post): please read the FAQ before posting questions and
replies, no matter how right you think you are. I have been using C for
over 14 years and still get surprised on occasion by certain constructs.
I still look in the FAQ before I ask or answer a question.

                                Z


--
-------------------------------------------------------------------------
| Syed Zaeem Hosain          P. O. Box 610097            [phone] |
| Z Consulting Group        San Jose, CA 95161             [e-mail] |
-------------------------------------------------------------------------